/ . , EL896636742US 

30006639US 

1 

TRUSTED SYSTEM 

Background Art 

5 Point-of-sale payment terminals are physical checkout devices currently used 
for credit, debit and smart card transactions, typically used in shops and small 
businesses and mainly owned by merchants and banks. These devices 
capture payment information at the point of sale and quickly transfer it from 
the merchant counter to the payment network for approval. An example 
10 provider is VeriFone™. Current products enable support for multiple 
^ applications or services - such as loyalty programs, payment, smart card 

S processing- at the point-of-sale. Furthermore, multiple applications, created by 

!,y different developers, can reside on one terminal and yet remain separate. 

;;; y 

p Various handheld and countertop peripheral products support multiple options 

]JJ * 15 for secure PINpad and smart card applications at the point of sale. These 
products allow merchants to accept both debit and smart card forms of 
K payment. 

2 However, various types of software attack are possible on these systems, 

" 20 additionally there is a danger that the merchant may cheat the customer out 

of money by putting through too much money or putting through a transaction 

twice. 

It is desirable to improve this situation. 

25 

Summary of the Invention 

In accordance with a first aspect of the present invention there is provided a 
method for allowing a financial transaction to be performed using a electronic 
30 system, the method comprising interrogating an electronic transaction 
terminal with an electronic security device to obtain an integrity metric for the 
electronic financial transaction terminal; determining if the transaction terminal 
is a trusted terminal based upon the integrity metric; allowing financial 
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transaction data to be input into the transaction terminal if the transaction 
terminal is identified as a trusted terminal. 

Preferably the method further comprises the providing of user identification 
5 data for the user of the electronic security data to the transaction terminal via 
the security device to allow authorisation of the transaction associated with 
the financial transaction data. 

In accordance with a second aspect of the present invention there is provided 
10 a financial transaction system comprising an electronic financial terminal; an 
electronic security device having interrogation means for interrogating the 
electronic financial transaction terminal to obtain an integrity metric for the 
electronic financial transaction terminal, determining means for determining if 
the transaction terminal is a trusted terminal based upon the integrity metric, 
15 means for allowing financial transaction data to be input into the transaction 
terminal if the transaction terminal is identified as a trusted terminal. 

In accordance with a third aspect of the present invention there is provided an 
electronic security transaction device having interrogation means for 

20 interrogating an electronic financial transaction terminal to obtain an integrity 
metric for the electronic financial transaction terminal, determining means for 
determining if the transaction terminal is a trusted terminal based upon the 
integrity metric, means for allowing financial transaction data to be input into 
the transaction terminal if the transaction terminal is identified as a trusted 

25 terminal. 

This invention seeks to provide secure payment transactions that can be used 
by customers in establishing trustworthiness of the payment procedure when 
entering into a transaction via a transaction terminal, otherwise known as a 
30 payment terminal, by means of the integrity checking of functional 
components in the payment terminal. Additionally, trusted feedback to the 
customer and a secure payment protocol can also be optionally provided. 
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The invention applies to all types of payment terminals, including countertop, 
portable or wireless payment terminals. 

Preferably trusted functionality is added to payment terminals in order to 
enhance the trustworthiness of the payment terminals and allow a user to 
check whether the transaction operation and payment is made in the 
expected manner. 

Additionally, this invention seeks to provide the user with increased trust and 
confidence in the payment transaction operation by means of defining a 
trusted transaction payment protocol and being able to check that this trusted 
transaction payment protocol is carried out. 

Preferably the payment terminal can be trusted by means of mutual 
authentication between the payment terminal and the electronic security 
device in addition to the electronic security device, for example a secure token 
or trusted personal device, carrying out an integrity check on the payment 
terminal. Either the result of this check is implicit, and the protocol will only be 
allowed to continue if the token or trusted personal device is satisfied as to the 
payment terminal's integrity, or the result of the check can be explicit, whereby 
the result of this check will be displayed on the trusted personal device or else 
a user's secret image will be displayed on the payment terminal itself. In the 
latter case the payment terminal should delete the secret once the transaction 
is complete, and part of the integrity check on the payment terminal should 
ensure that the terminal is configured for this to take place. If the result of the 
check is explicit, the user will only continue with the transaction payment if 
they are satisfied as to the trustworthiness of the payment terminal. 
Optionally, any result displayed to the user can include information relating to 
the trustworthiness of the bank. 
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Preferably the user's token or trusted personal device displays an image on 
the payment terminal with another special secret stored within the token or 
trusted personal device and previously unknown to the payment terminal, or 
else by displaying directly onto the trusted personal device. 

Preferably user authorisation for continuing the procedure of purchasing 
goods is by means of a hardware switch or software button that the consumer 
must press. The payment will be made once this button/switch is pressed. 
The software button could be associated with the image on the payment 
terminal or else could be displayed on the trusted personal device. 

p re f era bly compartmentalisation within the payment terminal is used to 
separate different types of transaction, such as different customers' 
transactions, different types of transaction (e.g. smart card, swipe card and 
debit card) or different banks. 

Preferably compartmentalisation within the trusted personal device is used to 
separate different types of communication. 

Preferably the electronic security device is a wireless trusted personal device 
on which the various images are displayed so that the consumer does not 
have to be in the same location as the payment terminal and therefore does 
not have to make payments at fixed points. 

The invention seeks to provide the advantage of allowing a customer to be 
able to trust that the payment operation can be trusted; that is to say that the 
payment operation will be carried out in an expected manner. This involves 
the customer needing to trust that the terminal itself is operating in the 
expected manner, that the bank is trustworthy, that the amount paid by the 
customer will be the amount that the customer expects to be charged, that the 
customer is buying the goods s/he expects. 
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Description of the Drawings 

Embodiment of the present invention will now be described in detail with 
reference to the accompanying drawings, of which: 

Figure 1 is a diagram that illustrates a system capable of implementing 
5 embodiments of the present invention; 

Figure 2 is a diagram which illustrates a motherboard including a trusted 
device arranged to communicate with a smart card via a smart card reader 
and with a group of modules; 

Figure 3 is a diagram that illustrates the trusted device in more detail; 
10 Figure 4 is a flow diagram which illustrates the steps involved in acquiring an 
integrity metric of the computing apparatus; 

Figure 5 is a diagram which illustrates a hardware architecture of a smart card 
processing engine suitable for operating in accordance with the preferred 
embodiment of the present invention; 
15 Figure 6 is a diagram which illustrates a functional architecture of a host 
computer including a trusted display processor and a smart card suitable for 
operating in accordance with the preferred embodiment of the present 
invention; 

Figure 7 is a flow diagram which illustrates the steps involved in displaying 
20 seal data. 

Description of the Preferred Embodiment 

For the purposes of this preferred embodiment a smart card is used as the 
security token, i.e. electronic security device, held by consumers. However, 
25 the security token could be, for example, secure pinpads, trusted PDAs or 
other trusted mobile computing apparatus. Optionally, these devices could 
themselves be trusted computing platforms containing a trusted component, 
as described below. 

30 In this preferred embodiment, there are four entities involved in the procedure 
of purchasing goods. They are an off-line certificate authority (CA) (not 
shown), a consumer with a smart card (SC) 19, a payment terminal 10, i.e. 
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electronic financial transaction terminal, with a trusted component (TC1), and 
a remote bank platform with a trusted component (TC2) (not shown). 

A platform 10 containing a trusted component, for example the payment 
5 terminal, is illustrated in the diagram in Figure 1, The platform 10 includes the 
standard features of a keyboard 14, mouse 16 and visual display unit (VDU) 
18, which provide the physical 'user interface' of the platform. In addition, the 
platform 10 has a trusted input device, in this case a trusted switch 11, which 
is integrated into the keyboard. This embodiment of a trusted platform also 

10 contains a smart card reader 12 and a local area network (not shown) which 
in turn is connected to the internet (not shown). Along side the smart card 
reader 12, there is illustrated a smart card 19 to allow trusted user interaction 
with the trusted platform as shall be described further below. In the platform 
10, there are a plurality of modules 15: these are other functional elements of 

15 the trusted platform of essentially any kind appropriate to that platform (the 
functional significance of such elements is not relevant to the present 
invention and will not be discussed further herein). 

As illustrated in Figure 2, the motherboard 20 of the trusted computing 
20 platform 10 includes (among other standard components) a main processor 
21, main memory 22, a trusted device 24, a data bus 26 and respective 
control lines 27 and lines 28, BIOS memory 29 containing the BIOS program 
for the platform 10 and an Input/Output (IO) device 23, which controls 
interaction between the components of the motherboard and the smart card 
25 reader 12, the keyboard 14, the mouse 16 and the VDU 18. Additionally, the 
motherboard 20 includes a LAN (local area network) adaptor 25 for 
connecting the platform 10 to a LAN (not shown), via which the platform 10 
can communicate with other host computers (not shown), such as file servers, 
print servers or email servers, and the Internet. The main memory 22 is 
30 typically random access memory (RAM). In operation, the platform 10 loads 
the operating system, for example Windows NT™, into RAM from hard disk 
(not shown). Additionally, in operation, the platform 10 loads the processes or 
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applications that may be executed by the platform 10 into RAM from hard disk 
(not shown). 

Typically, in a personal computer the BIOS program is located in a special 
5 reserved memory area, the upper 64K of the first megabyte do the system 
memory (addresses F000h to FFFFh), and the main processor is arranged 
to look at this memory location first, in accordance with an industry wide 
standard. 

10 The significant difference between the platform and a conventional platform 
is that, after reset, the main processor is initially controlled by the trusted 
device, which then hands control over to the platform-specific BIOS program, 
which in turn initialises all input/output devices as normal. After the BIOS 
program has executed, control is handed over as normal by the BIOS 

15 program to an operating system program, such as Windows NT (TM), which is 
typically loaded into main memory 22 from a hard disk drive (not shown). 

Clearly, this change from the normal procedure requires a modification to the 
implementation of the industry standard, whereby the main processor 21 is 
20 directed to address the trusted device 24 to receive its first instructions. This 
change may be made simply by hard-coding a different address into the main 
processor 21. Alternatively, the trusted device 24 may be assigned the 
standard BIOS program address, in which case there is no need to modify the 
main processor configuration. 

25 

It is highly desirable for the BIOS boot block to be contained within the trusted 
device 24. This prevents subversion of the obtaining of the integrity metric 
(IM) (which could otherwise occur if rogue software processes are present) 
and prevents rogue software processes creating a situation in which the BIOS 
30 (even if correct) fails to build the proper environment for the operating system. 
Although, in the preferred embodiment to be described, the trusted device 24 
is a single, discrete component, it is envisaged that the functions of the 
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trusted device 24 may alternatively be split into multiple devices on the 
motherboard, or even integrated into one or more of the existing standard 
devices of the platform. For example, it is feasible to integrate one or more of 
the functions of the trusted device into the main processor itself, provided that 
5 the functions and their communications cannot be subverted. This, however, 
would probably require separate leads on the processor for sole use by the 
trusted functions. Additionally or alternatively, although in the present 
embodiment the trusted device is a hardware device that is adapted for 
integration into the motherboard 20, it is anticipated that a trusted device may 

10 be implemented as a 'removable' device, such as a dongle, which could be 
attached to a platform when required. Whether the trusted device is 
integrated or removable is a matter of design choice. However, where the 
trusted device is separable, a mechanism for providing a logical binding 
between the trusted device and the platform should be present. Additionally, 

15 trusted device 24 handles all standard display functions plus a number of 
further tasks, which will be described in detail below. 'Standard display 
functions' are those functions that one would normally expect to find in any 
standard platform 10, for example a PC operating under the Windows NT™ 
operating system, for displaying an image associated with the operating 

20 system or application software. 



The trusted device 24 comprises a number of blocks, as illustrated in Figure 
3. After system reset, the trusted device 24 performs a secure boot process to 
ensure that the operating system of the platform 10 (including the system 

25 clock and the display on the monitor) is running properly and in a secure 
manner. During the secure boot process, the trusted device 24 acquires an 
integrity metric of the computing platform 10. The trusted device 24 can also 
perform secure data transfer and, for example, authentication between it and 
a smart card via encryption/decryption and signature/verification. The trusted 

30 device 24 can also securely enforce various security control policies, such as 
locking of the user interface. 
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Specifically, the trusted device comprises: a controller 30 programmed to 
control the overall operation of the trusted device 24, and interact with the 
other functions on the trusted device 24 and with the other devices on the 
motherboard 20; a measurement function 31 for acquiring the integrity metric 
5 from the platform 10; a cryptographic function 32 for signing, encrypting or 
decrypting specified data; an authentication function 33 for authenticating a 
smart card; and interface circuitry 34 having appropriate ports (36, 37 & 38) 
for connecting the trusted device 24 respectively to the data bus 26, control 
lines 27 and address lines 28 of the motherboard 20 for receiving, inter alia, 

10 signals from the trusted switch 11 and image data (i.e. graphics primitives) 
from the processor 21 and also trusted image data from the smartcard 19, as 
will be described. Additionally, the trusted device 24 includes frame buffer 
memory 35, which comprises sufficient VRAM (video RAM) in which to store 
at least one full image frame (a typical frame buffer memory 315 is 1-2 

15 Mbytes in size, for screen resolutions of 1280x768 supporting up to 16.7 
million colours); and a video DAC (digital to analogue converter) 39 for 
converting pixmap data into analogue signals for driving the (analogue) VDU 
18. 

20 Each of the blocks in the trusted device 24 has access (typically via the 
controller 30) to appropriate volatile memory areas 4 and/or non-volatile 
memory areas 3 of the trusted device 24. Additionally, the trusted device 24 
is designed, in a known manner, to be tamper resistant. 

25 It will be apparent from Figure 3 that the frame buffer memory 35 is only 
accessible by the trusted device 24 itself, and not by the processor 21 . This is 
ensures that the processor 21, or, more importantly, subversive application 
programs or viruses, cannot modify the pixmap during a trusted operation. Of 
course, it would be feasible to provide the same level of security even if the 

30 processor 21 could directly access the frame buffer memory 35, as long as 
the trusted device 24 were arranged to have ultimate control over when the 
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processor 24 could access the frame buffer memory 35. Obviously, this latter 
scheme would be more difficult to implement. 



f y 



A typical process by which graphics primitives are generated by a platform 10 
5 will now be described by way of background. Initially, an application program, 
which wishes to display a particular image, makes an appropriate call, via a 
graphical API (application programming interface), to the operating system. 
An API typically provides a standard interface for an application program to 
access specific underlying display functions, such as provided by Windows 

10 NT™, for the purposes of displaying an image. The API call causes the 
operating system to make respective graphics driver library routine calls, 
which result in the generation of graphics primitives specific to a display 
processor, which in this case is the trusted device 24. These graphics 
primitives are finally passed by the processor 21 to the trusted device 24. 

15 Example graphics primitives might be 'draw a line from point x to point y with 
thickness i! or 'fill an area bounded by points w, x, y and z with a colour a\ 



The control program of the controller 30 controls the controller to provide the 
standard display functions to process the received graphics primitives, 
20 specifically: 

receiving from the processor 21 and processing graphics primitives to form 
pixmap data which is directly representative of an image to be displayed on 
the VDU 18 screen, where the pixmap data generally includes intensity values 
for each of the red, green and blue dots of each addressable pixel on the 

25 VDU 18 screen; 

storing the pixmap data into the frame buffer memory 35; and 
periodically, for example sixty times a second, reading the pixmap data from 
the frame buffer memory 35, converting the data into analogue signals using 
the video DAC and transmitting the analogue signals to the VDU 18 to display 

30 the required image on the screen. 
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Apart from the standard display functions, the control program includes a 
function to mix display image data deceived from the processor 21 with 
trusted image data to form a single pixmap. The control program also 
manages interaction with the cryptographic processor and the trusted switch 
5 11. 

The trusted device 24 forms a part of the overall 'display system' of the 
platform 10; the other parts typically being display functions of the operating 
system, which can be 'called' by application programs and which access the 
standard display functions of the graphics processor, and the VDU 18. In 
other words, the 'display system' of a platform 10 comprises every piece of 
hardware or functionality which is concerned with displaying an image. 

For reasons of performance, the trusted device 24 may be implemented as an 
application specific integrated circuit (ASIC). However, for flexibility, the 
trusted device 24 is preferably an appropriately programmed micro-controller. 
Both ASICs and micro-controllers are well known in the art of microelectronics 
and will not be considered herein in any further detail. 

20 One item of data stored in the non-volatile memory 3 of the trusted device 24 
is a certificate 350. The certificate 350 contains at least a public key 351 of 
the trusted device 24 and an authenticated value 352 of the platform integrity 
metric measured by a trusted party (TP). The certificate 350 is signed by the 
TP using the TP's private key prior to it being stored in the trusted device 24. 

25 In later communications sessions, a user of the platform 10 can verify the 
integrity of the platform 10 by comparing the acquired integrity metric with the 
authentic integrity metric 352. If there is a match, the user can be confident 
that the platform 10 has not been subverted. Knowledge of the TP's 
generally-available public key enables simple verification of the certificate 

30 350. The non-volatile memory 35 also contains an identity (ID) label 353. 
The ID label 353 is a conventional ID label, for example a serial number, that 
is unique within some context. The ID label 353 is generally used for indexing 
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and labelling of data relevant to the trusted device 24, but is insufficient in 
itself to prove the identity of the platform 10 under trusted conditions. 

The trusted device 24 is equipped with at least one method of reliably 
5 measuring or acquiring the integrity metric of the computing platform 10 with 
which it is associated. In the present embodiment, the integrity metric is 
acquired by the measurement function 31 by generating a digest of the BIOS 
instructions in the BIOS memory. Such an acquired integrity metric, if verified 
as described above, gives a potential user of the platform 10 a high level of 
10 confidence that the platform 10 has not been subverted at a hardware, or 
BIOS program, level. Other known processes, for example virus checkers, 
will typically be in place to check that the operating system and application 
program code has not been subverted. 

15 The measurement function 31 has access to: non-volatile memory 3 for 
storing a hash program 354 and a private key 355 of the trusted device 24, 
and volatile memory 4 for storing acquired integrity metric in the form of a 
digest 361. In appropriate embodiments, the volatile memory 4 may also be 
used to store the public keys and associated ID labels 360a-360n of one or 

20 more authentic smart cards 19s that can be used to gain access to the 
platform 10. 

In one preferred implementation, as well as the digest, the integrity metric 
includes a Boolean value, which is stored in volatile memory 4 by the 
25 measurement function 31 , for reasons that will become apparent. 

A preferred process for acquiring an integrity metric will now be described with 
reference to Figure 4. 



30 



In step 500, at switch-on, the measurement function 31 monitors the activity 
of the main processor 21 on the data, control and address lines (26, 27 & 28) 
to determine whether the trusted device 24 is the first memory accessed. 
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Under conventional operation, a main processor would first be directed to the 
BIOS memory first in order to execute the BIOS program. However, in 
accordance with the present embodiment, the main processor 21 is directed 
to the trusted device 24, which acts as a memory. In step 505, if the trusted 
5 device 24 is the first memory accessed, in step 510, the measurement 
function 31 writes to volatile memory 3 a Boolean value which indicates that 
the trusted device 24 was the first memory accessed. Otherwise, in step 515, 
the measurement function writes a Boolean value which indicates that the 
trusted device 24 was not the first memory accessed. 

10 

In the event the trusted device 24 is not the first accessed, there is of course 
a chance that the trusted device 24 will not be accessed at all. This would be 
the case, for example, if the main processor 21 were manipulated to run the 
BIOS program first. Under these circumstances, the platform would operate, 
15 but would be unable to verify its integrity on demand, since the integrity metric 
would not be available. Further, if the trusted device 24 were accessed after 
the BIOS program had been accessed, the Boolean value would clearly 
indicate lack of integrity of the platform. 

20 In step 520, when (or if) accessed as a memory by the main processor 21 , the 
main processor 21 reads the stored native hash instructions 354 from the 
measurement function 31 in step 525, The hash instructions 354 are passed 
for processing by the main processor 21 over the data bus 26. In step 530, 
main processor 21 executes the hash instructions 354 and uses them, in step 

25 535, to compute a digest of the BIOS memory 29, by reading the contents of 
the BIOS memory 29 and processing those contents according to the hash 
program. In step 540, the main processor 21 writes the computed digest 361 
to the appropriate non-volatile memory location 4 in the trusted device 24. 
The measurement function 31, in step 545, then calls the BIOS program in 

30 the BIOS memory 29, and execution continues in a conventional manner. 
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Clearly, there are a number of different ways in which the integrity metric may 
be calculated, depending upon the scope of the trust required. The 
measurement of the BIOS program's integrity provides a fundamental check 
on the integrity of a platform's underlying processing environment. The 
5 integrity metric should be of such a form that it will enable reasoning about the 
validity of the boot process - the value of the integrity metric can be used to 
verify whether the platform booted using the correct BIOS. Optionally, 
individual functional blocks within the BIOS could have their own digest 
values, with an ensemble BIOS digest being a digest of these individual 
O 10 digests. This enables a policy to state which parts of BIOS operation are 
;Jl critical for an intended purpose, and which are irrelevant (in which case the 

;j! individual digests must be stored in such a manner that validity of operation 

P under the policy can be established). 



15 Other integrity checks could involve establishing that various other devices, 
components or apparatus attached to the platform are present and in correct 
working order. In one example, the BIOS programs associated with a SCSI 
controller could be verified to ensure communications with peripheral 
equipment could be trusted. In another example, the integrity of other 

20 devices, for example memory devices or co-processors, on the platform could 
be verified by enacting fixed challenge/response interactions to ensure 
consistent results. Where the trusted device 24 is a separable component, 
some such form of interaction is desirable to provide an appropriate logical 
binding between the trusted device 14 and the platform. Also, although in the 

25 present embodiment the trusted device 24 utilises the data bus as its main 
means of communication with other parts of the platform, it would be feasible, 
although not so convenient, to provide alternative communications paths, 
such as hard-wired paths or optical paths. Further, although in the present 
embodiment the trusted device 24 instructs the main processor 21 to calculate 

30 the integrity metric in other embodiments, the trusted device itself is arranged 
to measure one or more integrity metrics. 
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Preferably, the BIOS boot process includes mechanisms to verify the integrity 
of the boot process itself. Such mechanisms are already known from, for 
example, Intel's draft "Wired for Management baseline specification v 2.0 - 
BOOT Integrity Service", and involve calculating digests of software or 
5 firmware before loading that software or firmware. Such a computed digest is 
compared with a value stored in a certificate provided by a trusted entity, 
whose public key is known to the BIOS. The software/firmware is then loaded 
only if the computed value matches the expected value from the certificate, 
and the certificate has been proven valid by use of the trusted entity's public 
10 key. Otherwise, an appropriate exception handling routine is invoked. 

Optionally, after receiving the computed BIOS digest, the trusted device 24 
may inspect the proper value of the BIOS digest in the certificate and not pass 
control to the BIOS if the computed digest does not match the proper value. 
15 Additionally, or alternatively, the trusted device 24 may inspect the Boolean 
value and not pass control back to the BIOS if the trusted device 24 was not 
the first memory accessed. In either of these cases, an appropriate exception 
handling routine may be invoked. 

20 As already mentioned, the present embodiment relies on interaction between 
the trusted device 24 and the user's smartcard 19. The processing engine of 
a smartcard suitable for use in accordance with the preferred embodiment is 
illustrated in Figure 5. The processing engine comprises a processor 400 for 
enacting standard encryption and decryption functions, to support digital 

25 signing of data and verification of signatures received from elsewhere. In the 
present embodiment, the processor 50 is an 8-bit microcontroller, which has a 
built-in operating system and is arranged to communicate with the outside 
world via asynchronous protocols specified through ISO 7816-3, 4, T=0, T=1 
and T=14 standards. The smartcard also comprises non-volatile memory 52, 

30 for example flash memory, containing an identifier Isc of the smartcard 19, a 
private key S S c, used for digitally signing data, and a certificate Certsc, 
provided by a trusted third party certification agency (CA), which binds the 
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smartcard with public-private key pairs and includes the corresponding public 
keys of the smartcard 19 (the same in nature to the certificate Cert D p 350 of 
the trusted device 24). Further, the smartcard contains 'seal' data SEAL in 
the non-volatile memory 52, which can be represented graphically by the 
5 trusted device 24 to indicate to the user that a process is operating securely 
with the user's smartcard, as will be described in detail below. In the present 
embodiment, the seal data SEAL is in the form of an image pixmap, which 
was originally selected by the user as a unique identifier, for example an 
image of the user himself, and loaded into the smartcard 19 using well-known 
10 techniques. The processor 50 also has access to volatile memory 53, for 
example RAM, for storing state information (such as received keys) and 
providing a working area for the processor 50, and an interface 54, for 
example electrical contacts, for communicating with a smart card reader. 

15 Seal images can consume relatively large amounts of memory if stored as 
pixmaps. This may be a distinct disadvantage in circumstances where the 
image needs to be stored on a smartcard 19, where memory capacity is 
relatively limited. The memory requirement may be reduced by a number of 
different techniques. For example, the seal image could comprise: a 

20 compressed image, which can be decompressed by the trusted device 24; a 
thumb-nail image that forms the primitive element of a repeating mosaic 
generated by the trusted device 24; a naturally compressed image, such as a 
set of alphanumeric characters, which can be displayed by the trusted device 
24 as a single large image, or used as a thumb-nail image as above. In any 

25 of these alternatives, the seal data itself may be in encrypted form and require 
the trusted device 24 to decrypt the data before it can be displayed. 
Alternatively, the seal data may be an encrypted index, which identifies one of 
a number of possible images stored by the platform 10 or a network server. 
In this case, the index would be fetched by the trusted device 24 across a 

30 secure channel and decrypted in order to retrieve and display the correct 
image. Further, the seal data could comprise instructions (for example 
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PostScript™ instructions) that could be interpreted by an appropriately 
programmed trusted device 24 to generate an image. 

In accordance with Figure 6, the platform 10 includes functions provided by 
5 the trusted device 24. These functions are: a control process 62 for co- 
ordinating all the operations of the trusted device 24 and for receiving 
graphics primitives from a graphics primitives process (not shown) and from 
an application process 60; a seal process 63 for retrieving seal data 64 from 
the smartcard 1 9; a smartcard process 65 for interacting with the smartcard 

10 19 in order to enact challenge/response; and a trusted switch process 68 for 
monitoring whether the trusted switch 1 1 has been activated by the user. The 
smartcard process 65 has access to the trusted device's 24 identity data l D p, 
private key Sdp data and certificate Cert DP data 530. In practice, the smart 
card and the trusted device interact with one another via standard operating 

15 system calls. 

The smartcard 19 has: seal data 64; a display processor process 67 for 
interacting with the trusted device 24 to enact challenge/response and data 
signing tasks; smartcard identity data Isc, smartcard private key data Ssc and 
20 smartcard certificate data Certsc 66. 

A preferred process for recovering seal data using the arrangement shown in 
figures 1 to 6 will now be described: 

the control process 62 calls the seal process 63, and the seal process 63 calls 
25 the smartcard process 65, to recover the seal data 64 from the smartcard 19. 
Optionally, the control process 62 calls the generate pixmap process (not 
shown) to display another message indicating to the user that recovery of the 
seal data 64 is being attempted. The smartcard process 65 the trusted device 
24 and the display processor process 67 of the smartcard 19 interact using 
30 well known, 'challenge/response' techniques to enact mutual authentication 
and pass the seal data 64 from the smartcard and back to the control process 
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62. The details of the mutual authentication process and passing of the seal 
data 64 will now be described with reference to Figure 7. 

According to Figure 7, the smartcard process 65 sends a request REQ1 to the 
smartcard 19 to return the seal data SEAL 64. The display processor process 
67 generates a nonce Ri and sends it in a challenge to the smartcard process 
65. The smartcard process 65 generates a nonce R2 and concatenates it with 
nonce R1, signs the concatenation R1IIR2 with its private key to produce a 
signature sS D p(Ri||R2), and returns the concatenation R1IIR2, the signature 
sSdp(Ri||R2) and the certificate Certpp back to the display processor process 
67 of the smartcard 19. The display processor process 67 extracts the public 
key of the trusted device 24 from the certificate Cert D p 350, and uses this to 
authenticate the nonce R1 and the signature sSqp(Ri||R2) by comparison with 
the concatenation Ri||R 2 , to prove that the seal request came from the 
expected trusted device 24 and that the trusted device 24 is online. 

The nonces are used to protect the user from deception caused by replay of 
old but genuine signatures (called a 'replay attack') by untrustworthy 
processes. 

The display processor process 67 of the smartcard 19 then concatenates R2 
with its sea! data SEAL 64, signs the concatenation R2IISEAL using its private 
key Ssc to produce a signature sSsc(R2||SEAL), encrypts the seal data SEAL 
64 using its private key Ssc to produce encrypted seal data 64 sSsc(SEAL), 
and sends nonce R 2 , the encrypted seal data sSsc(SEAL), the signature 
sS S c(R2||SEAL) and the smartcard's certificate Cert S c to the smartcard 
process 65 of the trusted device 24. The smartcard process 65 extracts the 
smartcard's public key from the certificate Certsc and uses this to verify nonce 
R 2 and the signature sS S c(R2lISEAL), decrypt the seal data SEAL 64 from the 
encrypted seal data 64 sSsc(SEAL) and, finally, return the seal data SEAL 64, 
via the seal process 63, to the control process 62 for displaying on the VDU 
18. 
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Below is described an example of a consumer wishing to buy some goods 
from a vendor, via a payment terminal 10 based in a shop, using the 
customers smartcard 19 to ensure a secure payment transaction is 
5 established. To make a payment, the consumer is asked to insert his smart 
card 19 into the smart card reader 12. After the consumer does this, an image 
with a special seal generated by the smart card 19 and previously unknown to 
the payment terminal 10 is displayed on the VDU 18, confirming to the 
consumer that the smart card 19 is satisfied that the checkout box can be 
Q 10 trusted, as described above. Optionally, this special image can further confirm 
Jj to the consumer that the remote bank platform (not shown), which takes part 

in this payment process, can be trusted as well. 

ffl On inputting the details or code of the goods into either the smartcard 19 or 

^ 15 the payment terminal 10, an image with another special seal, again generated 

B by the smart card 19 and previously unknown to the payment terminal 10, is 

; j displayed on the VDU 18, confirming to the consumer that the smart card 19 

3 knows the price and product information. Associated with this image is a 

button, probably a hardware switch that the consumer must press in order to 
20 authorise continuing the procedure of purchasing goods, for example the 
switch 1 1 , however the button may be associated with a switch on smartcard 
19. In response to pressing the button, the payment is completed. 

For the purposes of authentication and key distribution, each entity has the 
25 following asymmetric key pairs: the CA (not shown) has a RSA key pair for 
signature and verification, the SC 19 has a RSA key pair for signature and 
verification and each of TC1 10 and TC2 (not shown) has at least a RSA key 
pair for signature and verification, or optionally, has two RSA key pairs 
respectively for signature-verification and encryption-decryption. 

30 
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A preferred protocol for implementing the above described preferred 
embodiment is described below. This protocol includes the security 
mechanisms of authentication amongst SC, TC1 and TC2, integrity checking 
of the checkout box with TC1 and the remote bank platform with TC2, and 
5 establishment of a transaction of the payment. 



On a consumer inserting the smart card into the smart card reader of the 
payment terminal to make a purchase TC1 of the payment terminal initiates 
the protocol by sending SC a first message containing (1) a command CMDi, 

y5 10 which is used to indicate different services and preferably including product 
description, service type, price and payment methods; (2) a newly generated 

' I nonce N^tcu and (3) the TC's certificate Cert(TC1) (if SC does not have this 

SJ certificate yet). 



15 Upon receipt of the first message from TC1 , SC replies to TC1 with a second 
message containing a newly generated nonce N 2 -sc, the name of TC2 and the 
SC's certificate Cert(SC) (if TC1 does not have this certificate yet). After 
receiving the second message 2, the payment terminal box connects to the 
remote bank platform. 



20 



On connection TC2 of the remote bank platform sends to TC1 a third 
message containing a newly generated nonce N3-TC2 and TC2 certificate 
Cert(TC2) (if TC1 hasn't got this certificate yet). 



25 In reply the third message TC1 sends TC2 a fourth message containing the 
command CMD1, the nonce N2.sc and the SC's certificate Cert(SC), forwarded 
from SC's message, and TC1's own certificate Cert(TC1) (if TC2 does not 
have this certificate). 
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Upon receipt of the fourth message, TC2 sends to TC1 a fifth message 
containing the integrity metric of the remote bank platform IMrc2 and a 
signature of CMD 1t N 2 -sc, N 3 _ T C2, User, TC1, IM TC 2 - {S T c2(CMD h N 2 -sc, N 3 .tc2, 
User, TC1, IM TC2 )}. 

5 

After receiving of the fifth message, TC1 sends to SC a sixth message 
containing N3-TC2, IM T ci, IM T c2, Cert(TC2), S T ci(CMD 1( N 2 -sc, Ni- TC i, User, 
TC2, IMtci), STC2(CMDi,N2.sc,N 3 -TC2,User,TC1,IMTC2) 

!^ 10 Upon receipt of the sixth message, SC verifies both signatures signed by TC1 

!IJ and TC2 S T ci S T c2. This allows the SC to authenticate and to perform an 

y integrity check on TC1 and TC2. If the verification is successful SC makes a 

f signature of CMDi, Ni. T ci, N 3 -tc 2 , N 2 -sc, TC1, TC2, E T ci(TID, SK1), E TC 2(SK2) 

3 - {S SC (CMD 1t Ni-rci, N 3 .tc2, N 2 -sc, TC1, 7C2, E TC i(TID, SK1), E T c2(SK2)}- 

1 15 including all the nonces being used in this session and two encrypted data 

2 respectively for TC1 and TC2. SC sends this signature {Ssc(CMD 1f N1-TC1, 

* tc2, N 2 sc, TC1, TC2,E TC i(TID, SK1), E T c2(SK2)}m a seventh message to TC1. 

1. TC1 -> TC2: SscfCMDj, N 2 -sc, TC1, TC2) 

20 After receiving of the seventh message, TC1 forwards the signature 
S sc (CMD h Ni-rvi, N3-TC2, N 2 -sc, TC1, TC2,E T ci(TID, SK1), E TC 2(SK2) to TC2. 

Both TC1 and TC2 then verify SC's signature. If this part of the protocol 
succeeds, TC2 will take the payment. 
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If during the flow of the above transaction protocol any verification or check is 
not successful, the corresponding verifier will make an announcement to let 
the other entities know what happens and then the protocol aborts. 
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If the information of the payment transaction is sensitive to any other party, 
the communications between TCI and TC2 can be protected, for example by 
using an encrypted channel. In this case, TC1 and TC2 can use their RSA 
encryption-decryption key pairs to establish an authenticated shared session 
5 key, and then use this session key to protect all message flows between 
them. 

Optionally, such technology can be incorporated with wireless technology 
such as Bluetooth (a wireless transmitter/ receiver programmed to allow a free 
10 flow of data without bulky cables, and designed to work anywhere). Using the 
protocol above with a (long-distance) wireless personal device instead of a 
smart card or connected personal device, transactions (payments) are 
brought to the consumer instead of the consumer having to make payments 
at fixed points. 



